Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
  • Records
  • TF_Legit.Health_Plus
    • Legit.Health Plus TF index
    • Legit.Health Plus STED
    • Legit.Health Plus description and specifications
    • R-TF-001-007 Declaration of conformity
    • GSPR
    • Clinical
    • Design and development
    • Design History File (DHF)
      • Version 1.0.0.0
        • Requirements
          • REQ_001 The user receives quantifiable data on the intensity of clinical signs
          • REQ_002 The user receives quantifiable data on the count of clinical signs
          • REQ_003 The user receives quantifiable data on the extent of clinical signs
          • REQ_004 The user receives an interpretative distribution representation of possible ICD categories represented in the pixels of the image
          • REQ_005 The user can send requests and get back the output of the device as a response in a secure, efficient and versatile manner
          • REQ_006 The data that users send and receive follows the FHIR healthcare interoperability standard
          • REQ_007 If something does not work, the API returns meaningful information about the error
          • REQ_008 Notify the user if the image does not represent a skin structure
          • REQ_009 Notify the user if the quality of the image is insufficient
          • REQ_010 The device detects if the image is of clinical or dermatoscopic modality
          • REQ_011 The user specifies the body site of the skin structure
          • REQ_012 Users can easily integrate the device into their system
          • REQ_013 The user receives the pixel coordinates of possible ICD categories
          • ignore-this
            • SWR-001- Users of the REST API can log in and receive an access token
            • SWR-002- The REST API enforces HTTPS for all communications to ensure data security
            • SWR-003- The REST API implements rate limiting to prevent abuse
            • SWR-004- The REST API verifies the access token for every request to secure endpoints
            • SWR-005- Data exchanged with clinical endpoints of the API adhere to the FHIR standard
            • SWR-006- The REST API only accepts and outputs images in Base64 format
            • SWR-007- The diagnosis support service accepts multiple images to deliver more accurate results
            • SWR-008- The user's password is stored in the database as a hashed password
            • SWR-009- New users of the device are only created by an internal user registration service
        • Test plans
        • Test runs
        • 🥣 SOUPs
    • IFU and label
    • Post-Market Surveillance
    • Quality control
    • Risk Management
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • TF_Legit.Health_Plus
  • Design History File (DHF)
  • Version 1.0.0.0
  • Requirements
  • ignore-this
  • SWR-003- The REST API implements rate limiting to prevent abuse

SWR-003- The REST API implements rate limiting to prevent abuse

Internal IDSWR_003
TitleThe REST API implements rate limiting to prevent abuse
CategoryFUNCTIONAL
ImportanceHIGH
SystemREST API
Editor(s)Alejandro Carmena Magro , JD-017
SupervisorAlfonso Medela , JD-005
ApprovalPENDING
Created at20 Jun 2024

Description​

Rate limiting is a mechanism to control the number of requests a client can make to the server within a specified time frame. It is essential for maintaining the stability and availability of the API, especially under conditions where multiple clients may make simultaneous or excessive requests. By setting rate limits, we can ensure everyone gets fair access, guard against abuse, and keep the server from being overloaded by too many requests from a single source.

Rate limiting should be flexible so we can configure different thresholds for various clients or endpoints. For example, we might impose stricter limits on anonymous users compared to authenticated ones, or adjust limits based on how sensitive or resource-intensive are the API endpoints being accessed.

The implementation should provide meaningful feedback to clients when their requests exceed the rate limit, such as returning an HTTP 429 Too Many Requests status code along with a message indicating the nature of the rate limit and when the client can retry their request. Additionally, detailed logging and monitoring should be in place to track rate limit violations and support troubleshooting and analysis of client behaviors.

To accommodate various use cases and ensure robustness, the rate limiting mechanism could employ algorithms such as the fixed window, sliding window, or token bucket. Each of these approaches has its own advantages and trade-offs in terms of precision and resource utilization.

Activities generated​

  • Define the rate limiting policies (e.g., maximum requests per minute/hour).
  • Implement rate limiting logic in the API (or on a reverse proxy server in front of the API).
  • Monitor and log rate limiting metrics.
  • Update API documentation to include rate limiting details.

Implements user needs​

This requirement ensures the API remains available and responsive for all users by preventing any single user or client from consuming disproportionate resources.

Causes failure modes​

  • Misconfigured rate limits leading to legitimate users being blocked.
  • Insufficient rate limits allowing abuse to continue.
  • Overly strict limits impacting user experience negatively.

Tested by software tests​

  • PLAN_007: Rate limiting for anonymous users
  • PLAN_008: Rate limiting for authenticated users
  • PLAN_009: Logging and monitoring of rate limit violations

Implements risk control measures​

  • Mitigate the risk of distributed denial-of-service (DDoS) attacks.
  • Ensure equitable resource distribution among users.

Acceptance criteria​

  • The API rejects requests exceeding the rate limit with a clear error message.
  • Rate limiting parameters are configurable.
  • Logs accurately reflect rate limit violations and actions taken.

Constraints​

There are no particular constraints for this requirement.

Dependencies​

  • Implemented an authentication service to verify client identities.
  • Logging and monitoring infrastructure to track rate limit metrics

Performance considerations​

  • Rate limiting logic does not significantly degrade API performance.

Additional notes​

In the future, we might consider using a sliding window or token bucket algorithm for rate limiting.

Revision history​

VersionDateAuthorDescription
Previous
SWR-002- The REST API enforces HTTPS for all communications to ensure data security
Next
SWR-004- The REST API verifies the access token for every request to secure endpoints
  • Description
  • Activities generated
  • Implements user needs
  • Causes failure modes
  • Tested by software tests
  • Implements risk control measures
  • Acceptance criteria
  • Constraints
  • Dependencies
  • Performance considerations
  • Additional notes
  • Revision history
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)